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(54) System and method for stub retrieval and loading 



(57) A stub retrieval and loading subsystem is dis- 
closed for use in connection with a remote method in- 
vocation system. The stub retrieval and loading subsys- 
tem controls the retrieval and loading ofa stub tor a re- 
mote method, into an execution environment, to facili- 
tate invocation of the remote method by a program ex- 
ecuting in the execution environment. The stub retrieval 
subsystem includes a stub retriever for initiating a re- 
trieval of the stub and stub loader for when the stub is 



received by the stub retriever loading the stub into the 
execution environment, thereby to make the stub avail- 
able for use in remote invocation of the remote method. 
In one embodiment, the stub retrieval and loading sub- 
system effects the retrieval and loading for a program 
operating in one address space provided by one com- 
puter of stub class instances to effect the remote invo- 
cation of methods which are provided by objects oper- 
ating in another address space, which may be provided 
by the same computer or a different computer 
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Description 



The invention relates generally to the field of digital 
computer systems, and more particularly to systems 
and methods for facilitating the invocation by a program 
being processed by a computer in one address space, 
of processing of methods and procedures in another ad- 
dress space, which may be implemented either on the 
same computer or on another computer. The invention 
particularly provides a system and method for obtaining 
and dynamically loading "stub" information which facili- 
tates invocation by a program operating in one address 
space of a remote method or procedure in another ad- 
dress space, and possibly on another computer. 

In modern 'enterprise" computing, a number of per- 
sonal computers, workstations, and other devices such 
as mass storage subsystems, network printers and in- 
terfaces to the public telephony system, are typically in- 
terconnected in one or more computer networks The 
personal computers and workstations are used by indi- 
vidual users to perform processing in connection with 
data and programs that may be stored in the network 
mass storage subsystems. In such an arrangement, the 
personal computers/workstations, operating as clients, 
typically download the data and programs from the net- 
work mass storage subsystems for processing. In addi- 
tion, the personal computers or workstations will enable 
processed data to be uploaded to the network mass 
storage subsystems for storage, to a network printer for 
pnnting, to the telephony interface for transmission over 
the public telephony system, or the like. In such an ar- 
rangement, the network mass storage subsystems, net- 
work printers and telephony interface operate as serv- 
ers, since they are available to service requests from all 
of the clients in the network. By organizing the network 
in such a manner, the servers are readily available for 
use by all of the personal computers/workstations in the 
network. Such a network may be spread over a fairly 
wide area, with the personal computers/workstations 
being interconnected by communication links such as 
electrical wires or optic fibers. 

In addition todownloading information from servers 
for processing, a client, while processing a program, can 
remotely initiate processing by a server computer of par- 
ticular routines and procedures (generally "proce- 
dures"), in connection with certain "parameter" informa- 
tion provided by the client. After the server has proc- 
essed the procedure, it will provide results of its process- 
ing to the client, which the client may thereafter use in 
its processing operations. Typically in such "remote pro- 
cedure calls" the program will make use of a local "stub" 
which, when called, transfers the request to the server 
which implements the particular procedure, receives the 
results and provides them to the program. Convention- 
ally, the stub must be compiled with the program, in ss 
which case the information needed to call the remote 
procedure must be determined at compile time, rather 
than at the time the program is run. Since the stub avail- 



able to the client's programs is static, it may be at best 
the closest that can be determined should be provided 
for the program when it (the program) is compiled. Ac- 
cordingly, errors and :nefficiencies can develop due to 
5 mismatches between the stub that is provided to a pro- 
gram and the requirements of the remote procedure thai 
is called when the program is run. 

The invention provides a new and improved system 
and method for facilitating the obtaining and dynamic 
10 loading ot a stub provided to enable a program operating 
in one address space to remotely invoke processing of 
a method or procedure in another address space, so 
that the stub can be loaded by the program when it is 
run and needed, rather than being statically determined 
15 when the program is compiled. Indeed, the stub that is 
loaded can be obtained from the resource providing the 
remote method or procedure, and so it (the stub) can 
exactly define the invocation requirements of the remote 
method or procedure. Since the stub can be located and 
20 dynamically loaded while the program is being run. rath- 
er that being statically determined when the program is 
compiled, run-time errors and inefficiencies which may 
result from mis-matches between the stub that is pro- 
vided and the requirements of the remote method or pro- 
25 cedure that is invoked can be minimized. 

In brief summary, the invention provides a stub re- 
trieval and loading subsystem for use in connection with 
a remote method invocation system. The stub retrieval 
and loading subsystem controls the retrieval and load- 
^0 ing of a stub for a remote method, into an execution en- 
vironment to facilitate invocation of the remote method 
by a program executing in the execution environment. 
The stub retrieval subsystem includes stub retriever for 
initiating a retrieval of the stub and stub loader for when 
35 the stub is received by the stub retriever loading the 
stub into the execution environment, thereby to make 
the stub available for use in remote invocation of the 
remote method In one embodiment, the stub retrieval 
and loading subsystem effects the retrieval and loading 
^0 for a program operating in one address space provided 
by one computer of stub class instances to effect the 
remote invocation of methods which are provided by ob- 
jects operating in another address space, which may be 
provided by the same computer or a different computer 
-^5 In that same embodiment, the stub retrieval and loading 
subsystem effects the retrieval and loading of a stub 
class instance when the remote object is referenced, al- ' 
though in other embodiments retrieval and loading may 
be effected when the remote method is invoked. 
50 This invention is pointed out with particularity in the 
appended claims. The above and further advantages of 
this invention may be better understood by referring to 
the following description taken in conjunction with the 
accompanying drawings, in which: 



FIG. 1 is a function block diagram of a computer 
network including an arrangement constructed in 
accordance with the invention for facilitating the ob- 



BNS0OCID:<£P 080381 1A2> 



2 



EP 0 803 811 A2 



laihing. dynamic loading and use ot "stub" inforrna- 
tion to enable a program operating in one address 
space to invoke processing of a remote method or 
procedure in another address space; 
FIGs. 2 and 3 are flow charts depicting the opera- 
tions performed by the arrangement depicted in 
FIG. 1 . which is useful in understanding the inven- 
tion, with FIG. 2 depicting operations performed in 
connection with obtaining and dynamic loading of 
the stub information and FIG. 3 depicting operations 
performed in connection with use of the stub infor- 
mation to invoke processing of the remote method 
or procedure. 

DETAILED DESCRIPTION OF AN ILLUSTRATIVE 
EMBODIMENT 

FIG. is a schematic diagram of a computer network 
10 including an arrangement for facilitating dynamic 
loading of "stub" information to enable a program oper- 
ating in one address space to remotely invoke process- 
ing of a method or procedure in another address space. 
With reference to FIG. 1 . computer network 10 includes 
a plurality of client computers 11(1) through 11 (N) (gen- 
erally identified by reference numeral 11 (n)). a plurality 
of server computers 12(1) through 12(M) (generally 
identified by reference numeral 12(m)), all of which are 
interconnected by a network represented by a commu- 
nication link 14. In addition, the network 10 may include 
at least one nameserver computer 13, which may also 
be connected to communication link 14. whose purpose 
will be described below. As is conventional, at least 
some of the client computers 1l(n) are in the form of 
personal computers or computer workstations, each of 
which typically includes a system unit, a video display 
unit and operator input devices such as a keyboard and 
mouse (all of which are not separately shown). The serv- 
er computers I2(m) and nameserver computer 1 3 also 
typically include a system unit (also not separately 
shown), and may also include a video display unit and 
operator input devices. 

The client computers 11 (n), server computers 12 
(m) and nameserver computer 1 3 are all of the conven- 
tional stored-program computer architecture. A system 
unit generally includes processing, memory, mass stor- 
age devices such as disk and/or tape storage elements 
and other elements (not separately shown), including 
network interface devices 15(n). 16(m) for interfacing 
the respective computer to the communication link 14. 
The video display unit permits the computer to display 
processed data and processing status to the operator 
and an operator input device enables the operator to in- 
put data and control processing by the computer. The 
computers 1 1 (n) and 1 2(m) and 1 3 transfer intormation. 
in the form of messages, through their respective net- 
work interface devices I5(n). 16(m) among each other 
over the communication link 14. 

In one embodiment, the network 10 is organized in 



a 'client-server* configuration, in which one or more 
computers, shown in FIG. 1 as computers 12{m). oper- 
ate as sen/ers, and the other computers, showri in FIG. 
1 as computers 11 (n) operate as clients. In one aspect. 
5 one or more of the server computers 1 2(m) may. as 'file 
servers/ include large-capacity mass storage devices 
which can store copies of programs and data which are 
available for retrieval by the client computers over the 
communication link 13 for use in their processing oper- 
10 ations. From time to time, a client computer 11 (n) may 
also store data on the sen/er computer 12. which may 
be later retrieved by it (the client computer that stored 
the data) or other client computers for use in their 
processing operations. In addition, one or more of the 
IS server computers l2(m) may. as "compute servers." 
perform certain processing operations in response to a 
remote request therefor from a client computer 11 (n). 
and return the results of the processing to the requesting 
client computer 1i(n) for use by them (that is. the re- 
20 questing client computers ll(n)) in their subsequent 
processing. In either case, the server computers may 
be generally similar to the client computers 11 (n). includ- 
ing a system unit, video display unit and operator input 
devices and may be usable by an operator for data 
2$ processing operations in a manner similar to a client 
computer Alternatively, at least some of the server com- 
puters may include only processing, memory, mass 
storage and network interface elements for receiving 
and processing retrieval, storage or remote processing 
30 requests from the client computers, and generating re- 
sponses thereto. It will be appreciated a client computer 
1 1 (n) may also perform operations described herein as 
being performed by a sen/er computer I2(m). and sim- 
ilarly a server computer I2(m) may also perform oper- 
as ations described herein as being performed by a client 
computer 1 1 (n). 

The network represented by communication link 14 
may comprise any of a number of types of networks over 
which client computers 11(n). server computers 12(m) 
40 and nameserver computers 13 may communicate, in- 
cluding, for example, local area networks (LANs) and 
wide area networks (WANs) which are typically main- 
tained within individual enterprises, the public telephony 
system, the Internet, and other networks, which may 
-fs transfer digital data among the various computers. The 
network may be implemented using any of a number of 
communication media, including, for example, wires, 
optical fibers, radio links, and/or other media for carrying 
signals representing information among the various 
50 computers depicted in FIG. 1. As noted above, each of 
the computers typically includes a network interface 
which connects the respective computer to the commu- 
nications link 14 and allows it to transmit and receive 
information thereover 
55 The invention provides a system for facilitating the 
obtaining and dynamic loading of "stub" information to 
enable a program operating in one address space to in- 
voke processing of a remote method or procedure in an- 
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other address space, which may be located on ihe same 
computer as the invoking program or on a different com- 
puter. The invention will be described in connection with 
programs provided in the Java™ programming lan- 
guage, as described in the Java language specification. s 
which are processed in connection with an execution 
environment which is provided by a Java virtual ma- 
chine. The Java virtual machine, in turn, is specified in 
the Java virtual machine specification. As described in 
the Java language specification, programs in the Java 
orogramming language define "classes' and 'interfac- 
es." Classes are used to define one or more methods 
or procedures, each of which may be invoked by refer- • 
ence to an interface. A class may be associated with 
and extend a "super-class," and in that regard will incor- is 
porate all of the interfaces and methods of the super- 
class, and may also include additional interfaces and/or 
methods. A class may also have one or more sub-class- 
es (and thus will comprise a super-class of each of its 
sub-classes), with each sub-class incorporating and 20 
possibly extending their respective super-classes. 

An interface provides a mechanism by which a set 
of methods may be declared. In that connection, an in- 
terface identifies each method that is declared by the 
interface by. for example, a name, identifies the data 
type(s) of argument(s) that are to be provided for the 
method, the data type(s) of return values that are to be 
returned by the method, and identifiers for exceptions 
which can be thrown during processing of the method. 
A class may indicate that it implements a particular in- 30 
terface. and in that connection will include the program 
code which will be used in processing all of the methods 
which are declared in the interface. In addition, different 
classes may indicate that they implement the same in- 
terface, and each will have program code which will be 35 
used in processing all of the methods which are de- 
clared in the interface, but the program code provided 
in each class to for use in processing the methods may 
differ from the program code provided in the other class- 
es which is used in processing the same methods: thus, -^o 
an interface provides a mechanism by which a set of 
methods can be declared without providing an indication 
of the procedure which will be used in processing any 
of the methods. An interface may be declared independ- 
ently of the particular class which implements the meth- -^s 
od or methods which can be invoked using the interface. 
In that regard, a class that invokes the method and a 
class that actually implements the method will not need 
to share a common super-class. 

Dunng processing of a Java program, as described so 
in the Java virtual machine specification, a client com- 
puter 11(n) provides an execution environment 20 for 
interpreting the Java program. The Java virtual machine 
includes a class loader 21 that, under control of a control 
module 19. can dynamically link instances of classes, 55 
generally identified in FIG. 1 by reference numeral 22. 
into the running program's execution environment while 
the program is being executed. In that operation, the 



control module 1 9 effectively enables the class loader 
- to retrieve un instantiated classes . which generally iden- 
tified by reference numeral 23. instantiate them and link 
them as class instances 22 into the execution environ- 
ment's address space at the Java program's run time as 
the methods which the respective classes 23 implement 
are called. In addition, the class toader 2l can discard 
ones of the class instances 22 when they a re not needed 
or to conserve memory, it will be appreciated that, if a 
class instance 22 has been discarded. itTnay be reload- 
ed by the class loader 21 at a later point if it is then need- 
ed. 

The invention provides an arrangement which facil- 
itates the remote invocation, by a program executing in 
an execution environment 20 by a client computer 1 1 (n). 
of methods implemented by classes on a server com- 
puter 12(m). In executing a method, the server computer 
12(m) will also provide an execution environment 24 for 
processing, under control of a control module 26. the 
Java method. In that operation, the Java virtual machine 
which provides the execution environment 21 includes 
a class loader 25 (which may be similar to the class load- 
er 21 ) that, under control of the control module 26. can 
dynamically link an instance of the class 26. to enable 
the method to be processed in the execution environ- 
ment 24. and instances of other classes (also generally 
represented by reference numeral 26) which may be 
needed to process the remotely-invoked method. In that 
operation, the control module 28 effectively enables the 
class loader 25 to retrieve an uninstantialed class for 
the method to be invoked, from a plurality of uninstanli- 
ated classes which are generally identified by reference 
numeral 27. instantiate it (that is. the uninstantiated 
class which provides the method to be invoked) and link 
it as a class instance 26 into the execution environment. 
In addition, the class loader 25 can discard the class 
instances 26 when processing of the method has termi- 
nated. It will be appreciated that, if class instances 26 
has been discarded, it may be reloaded by the class 
loader 25 at a later point if it is then needed. 

The structure of nameserver computer 1 3. if provid- 
ed is generally similar to that of the server computer 1 2 
(m). and will not be separately described. 

To facilitate remote invocation of a method, the con- 
trol module 19 of the client computer's execution envi- 
ronment 21 makes use of one or more stub class in- 
stances generally identified by reference numeral 30 * 
which are provided as part of the execution environment 
21 in which the various class instances 22. including the 
class instance which is invoking the remote method, are 
being processed Each stub class instance 30 is an in- 
stance of nn uninstantiated stub class 31, which the 
server computer l2fm) may maintain for the various 
class instances 25 ^nd uninstantiated classes 27 which 
the server computer 1 2(m) has "exported/ that is. which 
the sen/er computer I2(m) makes available to client 
computers 11 (n } for use in remote invocation of methods 
provided thereby An uninstantiated sub class 31 in- 
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eludes declarations for the complete set ot interfaces for 
the particular remote uninstantiated class 27 which im- 
plements the remote method to be invoked, and also 
provides or invokes methods which facilitate accessing 
of the remote method(s) which are implemented by the 
remote class. The uninstantiated stub class 31 . when it 
is instantiated and provided to the execution environ- 
ment 20 of the client computer 11 (n) as a stub class in- 
stance 30. effectively provides the information which is 
needed by the control module 1 9 of the execution envi- 
ronment 20 of the invoking Java program, so that, when 
a remote method that is implemented by its associated 
class is invoked by a Java program running in a partic- 
ular execution environment, the remote method will be 
processed and the return value(s) provided to the invok- 
ing Java program. In one embodiment, the arrangement 
by which the stub class instance may be provided to the 
execution environment 20 is similar to that described in 
the Waldo, et at. . patent application entitled "System and 
Method for Generating Identifiers for Uniquely Identify- 
ing Object Types for Objects Used in Processing of Ob- 
ject-Oriented Programs and the like*, having the same 
priority date of the present application. A copy ot the 
Waldo, et al.. patent application is filed herewith. 

m addition, the server computer I2(m) provides a 
skeleton 32, which identities the particular classes and 
methods which have been exported by the server com- 
puter I2(m) and information as to how it (that is. the 
server computer 1 2(m)) may load the respective classes 
and initiate processing of the particular methods provid- 
ed thereby. 

When a class instance invokes a remote method 
maintained by a server computer I2(m). it will provide 
values for various parameters to the stub class instance 
30 for the remote method, which values the remote 
method will use in its processing. II the remote method 
is implemented on the same computer as the invoking 
Java program, when the invoking Java program invokes 
a remote method, the computer may establish an exe- 
cution environment, similar to the execution environ- 
ment 20. enable the execution environment's class load- 
er to load and instantiate the class which implements 
the method as a class instance similar to class instances 
22. and process the remote method using values of pa- 
rameters which are provided by the invoking class in- 
stance in the remote invocation. After processing of the 
method has been completed, the execution environ- 
ment in which the remote method has been processed 
will provide the results to the stub class instance 30 for 
the remote method that was invoked, which, in turn, will 
provide to the particular class instance 22 which invoked 
the remote method. 

Similar operations will be performed if client com- 
puter 1 1 (n) and server computer 1 2{m) are implemented 
on different physical computers. In that case, in re- 
sponse to a remote invocation, the client computer 11 
(n) that is processing the invoking class instance 22. un- 
der control of the control module 19 for the execution 



environment 10 lor the invoking class instance 22. will 
use the appropriate stub class instance 30 to communi- 
cate over the network represented by the communica- 
tion link 1 4 with the server computer 1 2(m) which imple- 
5 ments the remote method to enable it (that is. the server 
computer 1 2(m)) to establish an execution environment 
24 for the class which implements the remote method, 
and to use the class loader 25 to load an instance of the 
class as a class instance 26. In addiiion.Jhe client com- 
10 puter 11 (n). also using the appropnate" stub class in- 
stance 30. will provide any required parameter values 
to the sen/er computer I2(m) over the network 14. 
Thereafter, the server computer I2(m) will process the 
remote method using parameter values so provided, to 
IS generate result value(s) which are transferred over the 
network to the client computer 11 (n). in particular to the 
appropriate stub class instance 30. The client computer 
I1(n) will, after it receives the result value(s) from the 
network, provide them to the invoking class instance 22 
20 for its processing. 

In any case, when the control module 1 9 of the client 
computer's execution environment 20 determines that 
a reference to the remote object has been received, if it 
determines that the stub class instance 30 is not present 
25 when it receives the reference, it will attempt to obtain 
the stub class instance 30 from, for example, the server 
computer l2(m) which implements the remote method, 
and enable the stub class instance 30 to be dynamically 
loaded in the execution environment 20 for the invoking 
30 Class instance 22. A reference to the remote object may 
be received, for example, either as a retum value of an- 
other remote method invocation or as a parameter that 
is received during another remote method invocation. 
The stub class instance may be dynamically loaded into 
35 the execution environment in a manner similar to that 
used to load class instances 22 in the execution envi- 
ronment 22. The execution environment 20 is provided 
with a stub class loader 33 which, under control of the 
control module 19. will attempt to find and load the stub 
40 class instances 30 as required by the class instances 
22 processed in the execution environment. The loca- 
tion ol a particular server computer 1 2(m) that maintains 
the class that implements a method to be invoked re- 
motely may be included in the call from the invoking 
-5 class instance or may be made known to the stub class 
loader 33 through another mechanism (not shown) 
maintained by the client computer 11 (n). 

However, if the stub class loader 33 is not olhenrt/ise 
noiilied ol which server computer I2(m) maintains the 
so class which implements a method which may be in- 
voked remoieiy ii may use the nameserver computer 
13 to provide thai identification. The identification may 
comprise any idcntitier which may be used to identify a 
server computer i2fm) or other resource which is avail- 
55 able on the network 1 4 and to which the server computer 
l2(m) can respond Illustrative identifiers include, for ex- 
ample, a network address which identifies the server 
computer and/or resource, or. if the network 14 is or in- 
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■ wSw^^ ^" for example, a World 

or a unilorm resource locator- CURL") which provides 
a uniform mechanism tor identifying resources thaTare 
available over the Internet. The se 'er com^u eM afri! 
^'h.ch implements the remote method, in response to a 
request from the client computer n (n) will provide smb 
Class instance 30 which the client computer lUntmav 
load into the execution environment 2^ to therlaf^ir en' 
able the remote invocation to be initiated 

As noted above, if the stub class loader 33 does no, 
know Which server computer ,2(m) implements thj re 
mote method Which may be invoked (a Jd thus does not" 
know p^^^.^^ ^ stub'ass code 

for the remote invocation), it may under control onn 
control module ,9. obtain the identi^L^^n °om the 

CaTs'toadrrST"" '^^ ^''^ ■ -ut 

Class oader 33 may use a previously-provided default 
stub c ass Which is provided tor use in such cases Thl 
default Class stub, when used by the invoking Java pro 
gram, enables the computer that is processino ,L 
voting Java program to communicate w '2 am'e 
server computer 1 3 to obtain information w^ ch can be 
used ,n invoking the remote method ThisTSa^on^ 
essentially the same as the invocation of a er^o "r^et " 
od to be processed by the nameserver compmeT J' 
with the remote method Including a parameter Trton.i 
-ng .he Class and method to be rern7e7ZKTZ 
enabling the nameserver computer 13 „° 5' " 

r.r::tr:rT^^°^-'^'~ 

ess the method to the requesting client computer mn) 

oTaZirhThT''^" ™^ ''^ '^^'p'"' - 

HiLdEing with the server commrtor ^r>/^^ ^ ■ 
.he panicular method. I. ^ ^d irih^ 

intormationTto ,h: e^oLTrl ""'"^'''^^ 
tains, and the namp« resources which it main- 
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.he control module lo hI. ^ However, if 

a stub class^n^f cfetemiines in step 101 that such 
virtmen, lo Sr^^^^^ "? "^^ --c"<*on en- 

andloadas.ubclassinstan?eMtoMh/?'"''''°'^^^^ 
.he remote method In Sauas^ h ^ 
Will initially determine StSeMhl """^"'^ ' ^ 

Class instance 227ncfurrt 1 'rom the 

the server cLp e??2,n,;:rorr'°"'" '° 

w~?.;rrthr'^"^^^^^^^^^^ 
- ^-.oa;r33r4Ta~drsu:^^ 

source locator (step 102) If th^ To!. . ^ 
loaa«r 33 receive, in. "" 
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stance 30 into execution environment 20 for the class 
instance 21 which initiated the rennote method invoca- 
tion call in step 100 (step 104). After the stub class in- 
stance 30 tor the referenced remote method has been 
loaded in the execution environment, the method can 
be invoked as will be described below in connection with 

Returning to step 102. if the control module 19 de- 
termines that the invocation from the class instance 22 
did not include a resource locator to identify the server 
computer I2(m) or other resource which maintains the 
class for the method to be invoke, and further that it {that 
is, the control module 1 9) or the stub class loader 33 is 
not otherwise provided with such a resource locator, a 
'class not found" exception may be indicated, at which 
point the control module 19 may call an exception han- 
dler. The exception handler may perform any of a 
number of recovery operations, including, for example, 
merely notifying the control module 19 that the remote 
method could not be located and allow it to determine 
subsequent operations. 

Alternatively, the control module 19 may attempt to 
obtain a resource locator from the nameserver compu- 
ter 13 or other resource provided by the network 14 
(generally represented in FIG. i by the nameserver 
computer 1 3). using a call to, for example, a default stub 
class instance 30. The call to the default stub class in- 
stance 30 will include an identification of the class and 
method to be invoked and the name ofthe nameserver 
computer I3(m). Using the default stub class instance 
30, the control module 19 will enable the computer 11 
(n) to initiate communications with nameserver compu- 
ter 1 3 to obtain an identifier for a server computer 1 2(m) 
which maintains the class and method to be invoked 
(step 110). The communications from the default stub 
class instance 30 will essentially correspond to a remote 
method invocation, with the method enabling the name- 
server computer to provide the identification for the serv- 
er computer I2(m), if one exists associated with the 
class and method to be remotely invoked, or alternative- 
ly to provide an indication that no server computer 12 
(m) is identified as being associated with the class and 
method. During the communications in step 110 the de- 
fault stub class interface 30 will provide, as a parameter 
value, the identification of class and method to be in- 
voked. 

In response to the communications from the default 
stub class instance 30, the nameserver computer 1 3 will 
process the request as a remote method (step ill), with 
the result information comprising Ihe^ identification for 
the server computer I2(m). if one exists that is associ- 
ated with the class and method to be remotely invoked, 
or alternatively an indication that no server computer 1 2 
(m) is identified as being associated with the class and 
method. After finishing the method, the nameserver 
computer 1 3 will initiate communications with the default 
stub class instance 30 to provide the result information 
to the default stub class instance 30 (step 112). 



After receipt of the result intormation from the 
namesen/er computer 13= the default stub class »n- 
stance, under control of the control module-1 9. will pass 
result information to the stub class loader 33 (step 113). 
5 Thereafter, the stub class loader 33 determines whether 
the result information from the nameserver computer 
comprises the identification for the server computer 1 2 
(m) or an indication that no server computer 12(m) is 
identified as being associated with the cjass (step 114V 
10 If the stub class loader 33 determines that the result in- 
formation comprises the identification for the server 
computer I2(m). it (that is, the stub class loader 33) will 
return to step 101 to initiate communication with the 
identified server computer 1 2(m) to obtain stub class in- 
is stance for the class and method that may be invoked. 
On the other hand, if the stub class loader 33 determines 
in step 114 that the nameserver computer 13 had pro- 
vided an indication that no server computer I2(m) is 
identified as being associated with the class and method 
20 that may be invoked, the "class not found" exception 
may be indicated (step 115) and an exception handler 
called as described above. 

As noted above, the stub class instance 30 re- 
trieved and loaded as described above in connection 
25 vvith FIG. 2 may be used in remote invocation of the 
method. Operations performed by the client computer 
11(n) in connection with remote invocation of the meth- 
od will be described in connection with the flow chart in 
FIG. 3. As depicted in FIG. 3, when a class instance 22 
30 invokes a method, the control module 19 may initially 
verify that a stub class instance 30 is present in the ex- 
ecution environment for remote method to be invoked 
(step 120) If a positive determination is made in step 
120. the stub class instance 30 will be used for the re- 
35 mote invocation, and in the remote invocation will pro- 
vide parameter values which are to be used in process- 
ing the remote method (step 121). Thereafter, the stub 
class instance 30 for the remote method that may be 
invoked will be used to initiate communications with the 
40 server computer 1 2(m) which maintains the class for the 
remote method (step 122). in the process, the passing 
parameter values which are to be used in processing 
the remote method will be passed. It will be appreciated 
that, if the server computer 12(m) which is to process 
•iS the method is the same physical computer as the client 
computer I2(n) which is invoking the method, the com- 
munications can be among execution environments 
which are being processed within the physical compu- 
ter. On the other hand, if the server computer I2(m) 
so which is to process the method is a different physical 
computer from that of the client computer 12(n) which 
is invoking the method, the communications will be 
through the client computer's and server computer's re- 
spective network tnterfaces 15(n) and 16(m) and over 
55 the network 14. 

In response to the communications from the stub 
class instance in step 122, the server computer 12(m), 
if necessary establishes an execution environment 24 
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for the class which maintains the method that may be 
invoked, and the uses the information provided by the 
Skeleton 32 to create a class instance 26 for that class 
(step 123). Thereafter, the server computer I2(m) un- 
der control of the control module 28. will process the 
method in connection with parameter values that were 
provided by stub class instance 30 (step 124) After 
completing processing of the method, the server com- 
puter 1 2(m), also under control of the control module 26 
will jnitiate communications with the client computer's 
stub Class instance 30 to provide result information to 
the stub Class instance (step 125). In a manner similar 
to that described above in connection with step 102 if 
the server computer 1 2(m) which processed the method 
IS the same physical computer as the client computer 
I2(n) Which invoked the method, the communications 
can be among execution environments 24 and 20 which 
are being processed within the physical computer On 
the other hand, if the server computer 1 2(m) which proc- 

!^ K w ! ' =°"iP"'er 12(n) which is invoking the 
method, the communications will be through the server 
computer's and client 7 computer's respective network 
interlaces 16(m) and I5(n) and over the network 14 Af- 
ter the stub 8 class instance 30 receives the result in- 
formation from the server computer, it may provide re- 
sul, information to the class instance 22 which initiated 
1/^"" 00""^""°^ invocation (step 126), and that class 
nstance 22 can continue processing under control of 
the control module 1 9. 

Returning to step 1 20. if the control module 1 9 de- 
termines ,n that step that it does not have a stub class 
■ns ance 30 that is appropriate for the remote method 

Uon handler (step 127) to perform selected error recov- 
ery operations 

The invention provides a number of advantages In 
ciluating dynamic loading of a stub which enables a pro- 

remoil^!' " T^'^""^ ^"^-^^''O" ^"^ironment to 

remotely invoke processing of a method ,n another ex- 
ecution environment, so that the stub can be loaded by 
the program when it is run and needed. In systems in 
Which stubs are compiled with the program, aid'h s 

Te^T""! '^^ P-9rL IS complied 

they (the stubs) may implement subsets of the actual 
set Of remote interfaces which are supported by the re 

cTntaTto e'" '''' thTprogra^,'!::;; 
can lead to errors and inefficiencies due to mismatches 
between the stub that ,s provided .0 a program and me 
Requirements of the remote procedure L is c^i ed 

oSm 1 '"'f '° '^^ provided to the invoking pro- 

iSfwrK"""' ''"^"'^ incompat- 
ibilities Which may result from mis-matches between the 



stub that is provided and the requirements of the remote 

method that is invoked 

It will be appreciated that a number of modifications 
may be made to the arrangement as described above 
' f'^^^P'^^ ^'»^°'^9h the execution environment 20 

has been described as obtaining and loading stub class 
instances to facilitate invocation of remote methods 
wtien references to the remote methods are recer.ed 

w ri!' HK^"^'^'^"^ '"Stances may in-" 

'0 stead be obtained and loaded when the remote methods 
are initially invoked. Obtaining and loading of the sS 
Class instance for a remote method when a reference 
Oiereto IS received will have the advantages that (i) the 
stub Class instance will be present in the execution In 

Torl^i .L ^PP'°P^'^'« class instance can not be 
located, the program or an operator may be notified ai 

"the'irr- °" ^'"^'"-s -^-9 

method IS to be invoked may result in a delay of the in- 
vocation until the correct stub class instance can' e 
found. If the method is in fact not invoked even if a ref 

nZ? '° '^"'"^^ s'"'' ^"Stance may not 
need to be located and loaded. 

with 1^'" appreciated that a system in accordance 
w^^h the invention can be constructed in whole or in part 
from special purpose hardware or a general purpose 
computer system, or any combination thereof, any por- 
ton of Which may be controlled by a suitable program 
■-0 Any program may in whole or in part comprise parfo^ or 
be stored on the system in a conventional manner. or° 
may in whole or in pan be provided in to the system over 
a network or other mechanism for transferring informal 
tion in a conventional manner In addition, it will be ap- 
•'S predated ,ha, the system may be operated and/or ol 
erwise controlled by means of information provided by 
an operator using operator input elements (not shown) 
Which may be connected directly to the system or whTch 
may transfer the information to the system over a net 
■'0 work or other mechanism for transferring informaJon'n 
a conventional manner 

cifi> '°;'^9°'"9='««=rip,ion has been limited toa spe- 
cific embodiment of this invention. It will be apparent 
- Se mld'e toTh'""" modifications r^a 

or a7oMhl =J ^na>nrnenl of some 

o all Of the advantages of the invention. I, is the object 
of the appended claims ,0 cover these and such o he ' 
variations and modifications as come within the true 
spirit and scope of the invention 

bva'cl^'nT""'''''''''^^''^""'"^^''^ performed 
by a computer program running on a computer in the 
embodiment described. Such a computer program can 
be recorded on a recording medium (for exampte a mTg 
netic disc or tape, an optical disc or an electronic r^rS- 
IZlJl. " ^ "^own to IhoTe 

a Sn '^^'"''"'^ -^^^-rn is read by 

a suitable reading device, such as a magnetic or optical 
disc drive, a signal is produced which causes a coC 
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ter to perform the processes described. 

The processes may also be performed by etectronic 
means. 

Claims 

1. For use in connection with a remote method invo- 
cation system, a stub retrieval and loading subsys- 
tem for controlling the retrieval and loading of a stub 
for a remote method into an execution environment 
to tacilitate invocation of the remote method by a 
program executing in said execution environment, 
the stub retrieval subsystem comprising: 

A. a stub retriever for initiating a retrieval of said 
stub: and 

B. a stub loader for, when said stub is received 
by said stub retriever, loading said stub into 
said execution environment, thereby to make 
the stub available for use in remote invocation 
of said remote method. 

2. A stub retrieval and loading subsystem as defined 
in claim 1 further including a remote method refer- 
ence detector for detecting whether a remote meth- 
od reference has been received in said execution 
environment, the stub retriever initiating retrieval of 
said stub when the remote method reference detec- 
tor detects that a remote method reference has 
been received in said execution environment. 

3. A stub retrieval and loading subsystem as defined 
in claim 1 further including a remote method invo- 
cation control for controlling invocation of said 're- 
mote method, said stub retriever initiating retrieval 
of said stub when the remote method is invoked 

4. For use in connection with a remote method invo- 
cation method, a stub retrieval and loading method 
for facilitating the retrieval and loading of a stub for 
a remote method into an execution environment to 
facilitate invocation of the remote method by a pro- 
gram executing in said execution environment, the 
stub retrieval method comprising the steps of: 

A. a stub retrieval step for initialing a retrieval 
of said stub; and 

B. a stub loading step for when said stub is re- 
ceived, loading said stub into said execution 
environment, thereby to make the stub availa- 
ble for use in remote invocation of said remote 
method. 

5. For use in connection with a remote method invo- 
cation method, a signal for controlling the retrieval 
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and loading of a stub for a remote method into an 
execution environment to facilitate invocation of the 
remote method by a program executing in said ex- 
ecution environment, the signal causing the com- 
5 puier to perform: 

A. a stub retrieval step for initiating a retrieval 
of said stub: and 

TO B. a stub loading step for. whefT said stub is re- 

ceived, leading said stub into said execution 
environment, thereby to make the stub availa- 
ble for use in remote invocation of said remote 
method. 

75 

6. A method of storing data on a recording medium, 
the method comprising storing data representative 
of a signal, which signal is (or use in connection with 
a remote method invocation method, the signal be- 
20 ing for controlling the retrieval and loading of a stub 
for a remote method into an execution environment 
to facilitate invocation of the remote method by a 
program executing in said execution environment, 
the signal causing the computer to perlorm: 

2S 

A. a stub retrieval step for initiating a retrieval 
of said stub: and 

B a stub loading step for. when said stub is re- 
30 ceived, loading said stub into said execution 

environment, thereby to make the stub availa- 
ble for use in remote invocation of. said remote 
method. 

35 7. A method as defined in claim 4 or 6. or a signal as 
defined in claim 5 further including a remote method 
reference detection step for detecting whether a re- 
mote method reference has been received in said 
execution environment, the stub retrieval step in- 

40 eluding the step of initiating retrieval of said stub 

when a remote method reference has been re- 
ceived in said execution environment. 

8. A method as defined in claim 4 or 6. or a signal as 
-iS defined in claim 5 further including a remote method 

invocation control step for controlling invocation of 
said remote method, said stub retrieval step includ- 
ing the step of initiating retrieval of said stub when 
the remote method is invoked. 

50 

9. For use in connection with a remote method invo- 
cation system, a stub retrieval and loading compu- 
ter program product for controlling a computer to, in 
turn, control the retrieval and loading of a stub (or a 

55 remote method into an execution environment to fa- 

cilitate invocation of the remote method by a pro- 
gram executing in said execution environment, the 
stub retrieval computer program product compris- 
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ing a computer-readable .medium havina encoded 
thereon: 
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for identifying said serv/er. 



A. stub retriever code devices to enable said 
computer to initiate a retrieval of said stub; and s 

B. a stub loader code devices to enable said 
computer to. when said stub is received, load- 
ing said stub into said execution environment, 
thereby to make the stub available for use in w 
remote invocation of said remote method. 

10. A stub retrieval and loading computer program 
product as defined in claim 9 further including re- 
mote method reference detector code devices for is 
enabling said computer to detect whether a remote 
method reference has been received in said execu- 
tion environment, the stub retriever code devices 
enabling said computer to initiate retrieval of said 
stub when the remote method reference detector 20 
code devices enable said computer to detect that a 
remote method reference has been received in said 
execution environment. 

11. A stub retrieval and loading computer program 25 
product as defined in claim 9 further including re- 
mote method invocation control code devices for 
enabling said computer to control invocation of said 
remote method, said stub retriever code devices 
enabling said computer to initiate retrieval of said 30 
stub when the remote method is invoked. 



1 2. A subsystem as defined in any one of claims 1 to 3. 
a method as defined in any one of claims 4 or 6 to 
o. computer program product as defined in any one 35 
of claims 9 to 1 1 . or a signal as defined in any ohe 
of claims 5 or 6 to 8. the remote method invocation 
system further including a server for processing 
said remote method in response to a processing re- 
quest therefor the server further providing said stub 40 
in response to a retrieval request from said stub re- 
triever. 

13. A subsystem, method, computer program product 

or signal as defined in claim 1 2 in which server pro- 45 
v.des a separate address space for processing said 
remote method from an address space provided by 
said execution environment. 

14. A subsystem, method, computer program product so 
or signal as defined in claim 1 3 in which the address 
space provided by said server and the address 
space provided by said execution environment are 
provided by separate computers. 

1 5. A stub retrieval and loading subsystem as defined 
•n claim 12. 13 or 14. further comprising a remote 
server identifier for providing a server identification 



16. A stub retrieval and loading subsystem as definea 
in claim 1 5 further including a remote method refer- 
ence detector for detecting whether a remote meth- 
od reference has been received in said execution 
environment, the remote method reference includ- 
ing a remote method server identifier the remote 
server identifier using the remote method server 
identifier as the server identification" 

17. A stub retncval and loading subsystem as defined 
in claim 15 further including a remote method invo- 
cation control for providing a remote method invo- 
cation Identification for controlling invocation of said 
remote method, the remote method invocation pro- 
viding a remote method server identifier the remote 
sen/er identifier using the remote method server 
Identifier as the server identification. 

1 8. A method or signal as defined in claim 1 2. 1 3 or 1 4 
■further compnsing a remote server identification 
step for providing a server identification for identify- 
ing said server 

19. A method or signal as defined in claim 18 further 
including a remote method reference detection step 
for detecting whether a remote method reference 
has been received in said execution environment 
the remote method reference including a remote 
method server identifier the remote method server 
Identifier being used during the remote method ref- 
erence detection step as the server identification. 

20. A method or signal as defined in claim 18 further 
including a remote method invocation control step 
for providing a remote method invocation identifica- 
tion for controlling invocation of said remote meth- 
od. the remote method invocation providing a re- 
mote method server identifier, the remote method 
server identifier being used during the remote meth- 
od reference detection step as the server identifica- 
tion. 

21. A subsystem as defined in claim 15. 16 on 9 or a 
method or signal as defined in claims 18 19 or 20 
the remote method invocation system further in- 
eluding a nameserver for providing a said sen/er 
Identification, said remote server identifier initiatino 
communication with said nameserver to obtain the 
server identification for said remote method. 

22. A stub retrieval and loading computer program 
product as defined in claim 12. 13 or 14 further 
compnsing remote server identifier code devices for 
enabling said computer to provide a server identifi- 
cation for identifying said server 
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23. A stub retrieval and loading computer program 
product as defined in claim 22 further including re- 
mote method reference detector code devices for 
enabling said computer to detect whether a remote 
method reference has been received in said execu- 
tion environment, the remote method reference in- 
cluding a remote method sender identifier, the re- 
mote server identifier code devices enabling said 
computer lo use the remote method server identifier 
as the server identification. 

24. A stub retrieval and loading computer program 
product as defined in claim 22 further including re- 
mote method invocation control code devices for 
enabling said computer to provide a remote method 
invocation identification for controlling invocation of 
said remote method, the remote method invocation 
providing a remote method server identifier, the re- 
mote server identifier code devices enabling said 
computer to use the remote method server identifier 
as the server identification, 

25. A stub retrieval and loading computer program 
product as defined in claim 22 the remote method 
invocation system further including a nameserver 
for providing a said server identification, said re- 
mote server identifier code devices enabling said 
computer to initiate communication with said name- 
server to obtain the server identification for said re- 
mote method. 

26. For use in connection with a remote method invo- 
cation system, a stub retrieval and loading subsys- 
tem for controlling the retrieval and loading of stub 
for a remote method into an execution environment 
to facilitate invocation of the remote method by a 
program executing in said execution environment, 
the stub retrieval subsystem comprising: 

A. a computer: and 

B. a control arrangement for controlling said 
computer, said control arrangement compris- 
ing: 

i. a stub retrieval module lor controlling said 
computer to initiate a retrieval of said stub, 
and 

ii. a stub loader module for controlling said 
computer to. when said stub is received in 
response to said stub retrieval module, 
load said stub into said execution environ- 
ment, thereby to make the stub available 
for use in remote invocation of said remote 
method. 

27. A control arrangement for use in connection with a 



computer to control the retrieval and loading ol a 
stub for a remote method into an execution environ- 
ment lo facilitate invocation of the remote method 
by a program executing in said execution environ- 
5 ment. said control arrangement comprising 

i. a stub retrieval module tor controlling satd 
computer to initiate a retrieval of said stub: and 

TO ii. a stub loader m.odule for confroUing said com- 

puter to. when said stub is received in response 
to said stub retrieval module, load said stub into 
said execution environment, thereby to make 
the stub available for use in remote invocation 

75 of said remote method. 

28. A system for distributing code stored on a computer 
readable medium and executable by a computer 
the code including a plurality of modules each con- 

20 figured to control the computer to facilitate the re- 

trieval and loading of a stub for a remote method 
into an execution environment to facilitate invoca- 
tion of the remote method by a program executing 
in said execution environment, said system com- 

25 prising: 

i. a stub retrieval module for controlling said 
computer to initiate a retrieval of said stub; and 

30 ii. a stub loader module for controlling said com- 

puter to. when said stub is received in response 
to said stub retrieval module, load said stub into 
said execution environment, thereby to make 
the stub available for use in remote invocation 

35 of said remote method. 

29. A signal according to any one of claims 5. 12 to 14. 
or 18 to 21 . wherein the signal is recorded on a re- 
cording medium. 

40 

30. A signal according to claim 29. wherein the record- 
ing medium comprises a magnetic disc, a magnetic 
tape, an optical disc or an electronic memory de- 
vice. 

45 
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100 EXECUTION ENVIRONMENT CONTROL 
DETERMINES WHETHER IT HAS A STUB CLASS 
APPROPRIATE FOR THE REMOTE METHOD FOR 
WHICH IT HAS A REFERENCE 



YES 



101. CONTINUE 



FIG. 2 



NO 



1 



102 CONTROL MODULE DETERMINES WHETHER 
INVOCATION INCLUDED A RESOURCE IDENTIFIER 
OR IF A RESOURCE IDENTIFIER FOR THE CALL IS 
OTHERWISE PROVIDED 



— r- 

YES 



103 CONTROL MODULE ENABLES STUB CLASS 
LOADER TO INITIATE COMMUNICATIONS WITH 
IDENTIFIED SERVER COMPUTER TO OBTAIN STUB 
CLASS INSTANCE FOR THE CLASS AND METHOD TO 
BE INVOKED 



I 



104. WHEN STUB CLASS LOADER RECEIVES STUB 
CLASS INSTANCE. CONTROL MODULE LOADS IT 
INTO EXECUTION ENVIRONMENT 
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F I G. 2 (CONT. A) 



/l10. CONTROL MODULE USES STUB CLASS 
LOADER IS CALLED TO. IN TURN. CALL DEFAULT 
STUB CLASS INSTANCE IS TO LOCATE 
APPROPRJATE SERVER COMPUTER INCLUDING 
IDENTIFICATION OF CLASS AND METHOD TO BE 
INVOKED 




111. NAMESERVER COMPUTER PROCESSES 
COMMUNICATIONS FROM DEFAULT STUB CLASS 

ORT^iM olt^ "^"^^^ INVOCATION. TO 

OBTAIN RESULT INFORMATION 



112. NAMESERVER COMPUTER INITIATES 
COMMUNICATIONS TO PROVIDE THE RESULT 
INFORMATION TO THE DEFAULT STUB CLASS 
INSTANCE 
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FIG. 2 (CONT. B) 



0 



0 



113. RESULT INFORMATION IS PROVIDED TO STUB 
CLASS LOADER 



RESOURCE 
IDENTIFIER 



114. STUB CLASS LOADER DETERMINES WHETHER 
RESULT INFORMATION IS A RESOURCE IDENTIFIER 
OR AN INDICATION THAT NO RESOURCE IDENTIFIER 
EXISTS FOR THE CLASS AND METHOD 



NO RESOURCE 
IDENTIFIER 



115. EXCEPTION 
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FIG. 3 



120. EXECUTION ENVIRONMENT CONTROL VERJFIES 

THAT IT HAS STUB CLASS INSTANCE FOR REMOTE 
METHOD WHICH HAS BEEN INVOKED 



YES 



121. CALL INTERFACE PROVIDED BY STUB CLASS 
INSTANCE TO INVOKE REMOTE METHOD 
Hccn .M PARAMETER VALUES WHICH ARE TO BE i 
USED IN PROCESSING THE REMOTE METHOD 



/l22^STUBCLftSS INSTANCE FOR REMOTE METHOD 
TO BE INVOKED INITIATES COMMUNICATIONS w^?h 
SERVER COMPUTER WHICH MAINTAINS ClJ^SsToR 
REMOTE METHOD. IN THE PROCESS PASsIng 
PARAMETER VALUES WHICH ARE TO BE USED IN i 
PROCESSING THE REMOTE METHOD 



123. SERVER COMPUTER ESTABLISHES AN 
EXECUTION ENVIRONMENT FOR METHOD TO BF 
INVOKED. USES INFORMATION PRO JiDED I? 
SKELETON TO CREATE A CL^SS INSTANCE FOR 
INVOK^^^ "''^"^^A'^S ^HE METHOD TO BE 
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FIG. s rCONT.A) 



o 



124 SERVER COMPUTER PROCESSES THE METHOD 
IN CONNECTION WITH PARAMETER VALUES 
PROVIDED BY STUB CLASS INSTANCE 



125 SERVER COMPUTER INITIATES 
COMMUNICATIONS WITH THE STUB CLASS 
INSTANCE TO PROVIDE RESULT INFORMATION TO 
THE STUB CLASS INSTANCE 



126 STUB CLASS INSTANCE RECEIVES RESULT 
AND PROVIDES RESULT INFORMATION TO CALLING 
CLASS INSTANCE 



127. EXCEPTION 



] 
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